BTW, we could also split up the docker-compose.yml into a fixed (template) part and then include the generated configs. (So for example, we could include docker-compose.servers.yml and docker-compose.processors.yml.)

@joschrew what about the processor resources, shouldn't that be a volume, too?

Preferably as named volume (so module-distributed and user-downloaded files can mix freely), e.g.:

Unfortunately, it seems we missed the opportunity of the latest sweep across modules to define a unique internal resource location. In ocrd/tesserocr, we already use /models as alias for /usr/local/share/ocrd-resources, but in many other images we still use the latter...

Perhaps brevity (/models instead of /usr/local/share/ocrd-resources) is not an issue if we are using scriped mounts and calls, anyway. And /models was a hack of sorts: it was not backed by the spec (which still says /usr/local is the system location, and $XDG_DATA_DIR the data location), but only a convention for our fat container images.

Therefore I will switch ocrd/tesserocr back to /usr/local/share/ocrd-resources as the only place to mount (as in all the other workable slim container images).

Therefore I will switch ocrd/tesserocr back to /usr/local/share/ocrd-resources as the only place to mount (as in all the other workable slim container images).

OCR-D/ocrd_tesserocr@70caca0

I have added a resource-volume now. What would you suggest to get the resources into the volume? I tried using the resmgr which fails because of missing writing permission on /.config (the setup cannot not use root permissions). Would it be a good idea to to this via the Makefile?

What would you suggest to get the resources into the volume? I tried using the resmgr which fails because of missing writing permission on /.config (the setup cannot not use root permissions). Would it be a good idea to to this via the Makefile?

Ah, that bit us before in the fat containers, so I thought we found a remedy for it: setting XDG_CONFIG_HOME=/usr/local/share/ocrd-resources as well, so the volume should cover both the resources themselves and the config file ocrd/resources.yml.

Your /.config indicates that XDG_CONFIG_HOME is not set (as HOME=/). What image is this happening with?

So no, this should work on the user side already.

All images. The setup is started as current user, this is necessary because the created workspace files should be of user's permission. If the volume is of root permission (or a named volume, same permissions) the resource download can only triggered by root. But when the container is started as user and then root user is used to download the resources we have logfile permission-errors again. The value of XDG_CONFIG_HOME has no effect on permissions.

Oh, right! We do have a problem with named volumes. They are always created as root. Even with docker volume create. It seems the only way to get normal ownership is by choosing a container-side parent path which already has the permissions we want (as these get inherited by the named volume). But in cases where the directory itself already exists (from the Docker build), its ownership won't change (i.e. stay root). That is a big problem.

The value of XDG_CONFIG_HOME has no effect on permissions.

It does have the effect of controlling where ocrd/resources.yml gets written.

See moby/moby#3124

Okay, so the only way out AFAICS is setting /usr/local/share/ocrd-resources (and its subdirectories) to 777 in the Dockerfile already. This means in every Dockerfile.

You can test this:

• revert a9f2ffd
• write a Dockerfile.fixup, contents:

ARG BASE_IMAGE
FROM $BASE_IMAGE
RUN mkdir -p /usr/local/share/ocrd-resources
RUN find /usr/local/share/ocrd-resources -type d -exec chmod 777 {} ";"
RUN find /usr/local/share/ocrd-resources -type f -exec chmod 666 {} ";"

• use it to patch a module of your choice, e.g.:

cat Dockerfile.fixup | docker build --build-arg BASE_IMAGE=ocrd/tesserocr -t ocrd/tesserocr:permissions -

• use the patched image, e.g.:

docker run --rm -it -v ocrd-resources:/usr/local/share/ocrd-resources ocrd/tesserocr:permissions ocrd resmgr download ocrd-tesserocr-recognize fra.traineddata

I tried your suggestion, it nearly works for me (setting /usr/local/share/ocrd-resources itself to 777 is also necessary).
Another possibility would be to have more than one folder for the resources (kind of what we have currently). /usr/local/share/ocrd-resoucres could be used for preinstalled resources and the "on-demand"-resources could be installed to another folder (XDG_DATA_HOME/ocrd-resources for example) and for that folder a host-mounted-volume could be used. I'd prefer one folder for all resources but setting global permissions might rise security concerns again like it did when we talked about setting permissions for the logging-folders. Did we have a reason why we don't want to use XDG_DATA_HOME/ocrd-resources?

Edit: suggestion works as expected, I forgot to reset (delete) the mounted named volume

it nearly works for me (setting /usr/local/share/ocrd-resources itself to 777 is also necessary).

Are you sure you tried the exact command above (which should already cover the top-level directory as well)?

Another possibility would be to have more than one folder for the resources [...]
Did we have a reason why we don't want to use XDG_DATA_HOME/ocrd-resources?

Yes, we did have a reason. Not all processors can handle more than 1 location. Tesseract for example can not be brought to look up in more than 1 directory.

It's also not intuitive. You don't want to have to think about resources in terms of where they came from.